System and method for using a portable security device to cryptograhically sign a document in response to signature requests from a relying pary to a digital signature

ABSTRACT

A system, method and computer-readable storage medium with instructions for operating a digital signature server and a portable security device to cooperate to provide digital signature services using a private key stored on the portable security device by delegating to a user&#39;s smart card the actual task of digitally signing documents. Other systems and methods are disclosed.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Patent Cooperation Treaty application claimingpriority from U.S. provisional application Ser. No. 61/311760, filed onMar. 8, 2010, entitled “SYSTEM AND METHOD FOR USING A SMART CARD TOCRYPTOGRAPHICALLY SIGN A DOCUMENT IN RESPONSE TO SIGNATURE REQUESTS FROMA RELYING PARTY TO A DIGITAL SIGNATURE SERVICE,” the teachings of whichare incorporated by reference herein as if reproduced in full below.

BACKGROUND OF THE INVENTION

The present invention relates generally to cryptographic signing ofelectronic documents, and in particular to using a smart card to sign adocument for a user in response to a request to have the document signedfor the user by a network signing service.

OASIS Digital Signature Service (DSS) is an OASIS standard thatdescribes how a digital signature service can be provided. The DSSSpecification (“Digital Signature Service Core Protocols, Elements, andBindings,” version 1.0, OASIS standard, Apr. 11, 2007.) details thedigital signature service core protocols, elements, and bindings. TheDSS Specification says:

“This (DSS) specification describes two XML-based request/responseprotocols—a signing protocol and a verifying protocol. Through theseprotocols a client can send documents (or document hashes) to a serverand receive back a signature on the documents; or send documents (ordocument hashes) and a signature to a server, and receive back an answeron whether the signature verifies the documents.”

Different applications, i.e., different relying parties, may havedifferent requirements for signing and verifying signatures. DSS handlesthis requirement through different DSS profiles, such as abstractcode-signing profile, XML time-stamping profile, German signature lawprofile, and so on. The DSS provides a centralized service model so thatapplications can ask for signature services from a DSS server instead ofhaving to deal with signature-related complexities themselves.

Digital signing is a cryptographic operation that uses the private keyof a {public key, private key} pair. The private key belongs to itsowner, must be securely stored, and should not be given to anyone else.In OASIS DSS, DSS manages or accesses private keys (also called signingkeys), eliminating the need of distributing user keys and/or signingdevices/software. The DSS model works well for signatures on anorganization's behalf, such as code signing, business agreements, pressrelease, and so on.

Using OASIS DSS, how the digital signature is created is not relevant toa relying party (RP). The OASIS DSS model works as long as the DSSserver can access users' private keys. However, if the private keys arein users' smart cards, the keys are not directly accessible by the DSSserver and the model breaks down

Some signature requirements conflict with the DSS model of storing theprivate keys on a central server; for example, certain Europeancountries require that the private key stays with the user. Furthermore,for the centralized model, the security of the digital signing dependson the strength of the user authentication. Most of the authenticationsystems use usernames and passwords, one of the weakest forms ofauthentication. If a user's username and password are compromised, theattacker can sign documents without the user's knowledge, which couldresult in personal or organizational damage.

For individual signatures, the DSS model of centralized key managementis less attractive. Many corporations, government agencies, and othershave deployed the smart card infrastructure to use smart cards to secureprivate information associated with an individual user to allow forlogical and physical access and to store individual secure information,e.g., the private keys. Each user within the organization has a smartcard with private and public key pairs stored in it.

Often, these organizations require users to digitally sign documents,such as emails, using their smart cards. In this situation, the smartcard works with the host application, for example Microsoft's emailsoftware, Outlook. The host application communicates with the smart cardand asks the card to perform the digital signing operation through somemiddleware running on the host computer. The smart card carries theuser's private key. It requires user authentication before performingany operations that involve the private key. This provides a two-factorsecurity protection (what-you-know and what-you-have), which mitigatesthe risk mentioned above: the private key stays with the user; acompromised pair of username and password does not lead to a forgeddigital signature. However, there is no standard way of using smartcards to sign documents from web applications. Furthermore, each webapplication or RP that requires a user to digitally sign using a smartcard must know how to communicate with the card.

Thus, DSS and smart card enabled digital signature mechanisms havecertain advantages and disadvantages. It would be desirable to combinethe advantages while overcoming the disadvantages to providesmart-card-based digital signatures to Web applications through amechanism similar to DSS or as an enhancement to DSS.

From the foregoing it will be apparent that there is still a need for animproved method to provide a secure mechanism under which a portablesecurity device, e.g., a smart card, connected to a host computer andhaving the capability of providing cryptographic signing services maycryptographically sign electronic documents on behalf of a user.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic illustration of a network connecting a hostcomputer (with a portable security device, e.g., a smart card, connectedthere to), a relying party (RP) and a digital signature server.

FIG. 2 is a schematic illustration of a portable security device.

FIG. 3 is a schematic illustration of a functional centralized signatureservice offered to relying parties in which a smart card may be used inconjunction with a digital signature server to provide digitalsignatures on documents, or other data, presented from a relying partyfor signature on behalf of a user.

FIG. 4 is a schematic illustrating the SignRequest and SignResponse in aprior art standard OASIS DSS signing protocol.

FIG. 5 illustrates an example to illustrate the workflow of a relyingparty using DSS to have a user to sign a document using the user's smartcard.

FIG. 6 is a timing-sequence diagram illustrating the HTTP Post bindingfor DSS request and response as used by the technology presented hereinbetween a user agent, e.g., the web browser, a DSS requester, e.g., arelying party, and a DSS responder 605, e.g., the DSS server.

FIG. 7 is a timing-sequence diagram illustrating the artifact bindingfor DSS request and response as used by the technology presented herein.

FIG. 8 is a block diagram illustrating the DSS web server side softwarearchitecture, i.e., one example of the software architecture for the DSSservice 119. Open source libraries and frameworks are used as buildingblocks.

The FIG. 9 is a schematic illustration illustrating the relationshipsbetween the various software modules and computers used to provide thedigital signature services of the present technology.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description, reference is made to theaccompanying drawings that show, by way of illustration, specificembodiments in which the invention may be practiced. These embodimentsare described in sufficient detail to enable those skilled in the art topractice the invention. It is to be understood that the variousembodiments of the invention, although different, are not necessarilymutually exclusive. For example, a particular feature, structure, orcharacteristic described herein in connection with one embodiment may beimplemented within other embodiments without departing from the spiritand scope of the invention. In addition, it is to be understood that thelocation or arrangement of individual elements within each disclosedembodiment may be modified without departing from the spirit and scopeof the invention. The following detailed description is, therefore, notto be taken in a limiting sense, and the scope of the present inventionis defined only by the appended claims, appropriately interpreted, alongwith the full range of equivalents to which the claims are entitled. Inthe drawings, like numerals refer to the same or similar functionalitythroughout the several views.

In an embodiment of the invention, a technology is provided that enablesthe use of smart cards, or other portable security devices, to be usedto digitally sign documents using private keys stored on the smartcards, for example, in conjunction with Web applications.

A method for operating a digital signature server and a portablesecurity device to cooperate to provide digital signature services usinga private key stored on the portable security device includestransmitting from a replying party a digital signature request to thedigital signature server via a web browser instance operating on a hostcomputer to which the portable security device is connected andreceiving, by the digital signature server, the digital signaturerequest from a relying party via the web browser instance executing onthe host computer. The method further includes, in response to receivingthe digital signature request, securely transmitting data to be signedfrom the digital signature server to the web browser instance executingon the host computer with an indication to operate the portable securitydevice to sign the document and forwarding the data to be signed fromthe web browser instance executing on the host computer to the portablesecurity device for signature. Further, the method includes operatingthe portable security device to digitally sign the data using a userprivate key stored on the portable security device, transmitting thedigital signature from the portable security device to the digitalsignature server via the web browser instance executing on the hostcomputer, and transmitting the digital signature from the digitalsignature server to the relying party via the web browser instanceexecuting on the host computer.

A system for implementing the above-described method (which is furtherdescribed in greater detail below) includes a digital signature serverhaving thereon a computer-readable storage medium including instructionsto direct the digital signature server to perform the functionality of adigital signature server in the above-described method. The systemfurther includes a relying party which implements the functionality ofthe relying party as described herein above and in greater detail below.Finally, the system includes a host computer on which a user mayinteract with the relying party via a web browser. A portable securitydevice, e.g., a smart card, is connected (or may be wirelesslyconnected) to the host computer. The host computer, from within the webbrowser, executes the functionality of the host computer in the methoddescribed herein above and further described in greater detail below.The functionality of the host computer is, in part, provided byexecuting, for example, from within a web browser, a web client fordigital signature services that may be dynamically loaded from thedigital signature server.

1.0 Introduction and Functional Model

Smart cards are plastic cards with an embedded microprocessor and asecure storage. They are portable, secure, and tamper-resistant. Smartcards provide security services in many domains includingtelecommunication, banking, and citizen identity. There are several formfactors used for smart cards including credit card shaped cards withelectrical connectors to connect the smart card to a smart card reader,USB tokens with embedded smart cards, and SIM cards for use in mobiletelephones. Smart cards are used herein as examples of portable securitydevices that may be used in implementations of the technology describedherein. Other examples of portable security devices include smart memorycards, flash memory, etc. In a preferred embodiment, the portablesecurity device has a processor, a memory for storing programs and data,and some security features to make the device relatively tamper proof.Smart cards meet these requirements.

Digital signature is one of the functions that smart cards provide. Thecard stores private or secret keys in its secure storage and performscryptographic operations to generate digital signature for a giveninput. A smart card works with a host device, such as a personalcomputer (PC), a cell phone, or a banking terminal. Typically, a PCapplication, such as an email client, works with a smart card to sign,encrypt, or decrypt a document. The PC application and the smart cardinteract through some cryptographic API called middleware, which knowshow to communicate with the smart card. In this scenario, the smart cardprovides services locally to the PC.

FIG. 1 is a schematic illustration of a network 111 connecting a hostcomputer 103 (with a portable security device 109, e.g., a smart card,connected thereto), a relying party (RP) 113 and a digital signatureserver 117. The host computer 103 is operated by a user 101 whointeracts with the RP 113 via a web browser window 105 of a web browser.

FIG. 2 is a schematic illustration of a portable security device 109.The portable security device 109 may include a processor 201 connectedvia a bus to a memory 203 and a non-volatile memory (NVM) 205. The NVM205 may include computer programs 207. These programs 207 includeoperating system programs as well as application programs loaded on tothe portable security device 109. The NVM 205 may also contain privatedata, such as a private key 209. The processor 201 may be furtherconnected to connectors 211 by which the portable security device 109may be connected to a host computer 103.

The portable security device 109 programs 207 may include a digitalsignature module 213, a user authentication module 215, a communicationsmodule 217, and operating system OS 219.

Thus, the portable security device 109 may receive a document via theconnector 211. The processor 201, by executing instructions of thedigital signature module 213, may digitally sign the document using theprivate key 209. Using functionality provided through the communicationsmodule 217, the processor 201 may receive and transmit communicationswith the host computer 103 and via the host computer 103 communicationsmodule 217.

FIG. 3 is a schematic illustration of a functional centralized signatureservice offered to relying parties in which a smart card 109 may be usedin conjunction with a digital signature server 117 to provide digitalsignatures on documents, or other data, presented from a relying party113 for signature on behalf of a user 101.

The following defines the context of the operation presented in FIG. 3:

1. The Digital Signature Service (DSS) 117 operates in a trustedassociation based on an established trust framework.

2. The DSS server 117 provides signature services for relying parties113, which are within the same circle of trust as the DSS server 117.

3. The end user's 101 public key and corresponding private key 209 arestored in the end user's 101 smart card 109 or other local devices thatthe user has control over.

4. The smart card 109 has capability to perform digital signatures.

5. The private key 209 never leaves the smart card 109.

6. The relying party 113 may not have means to access user's smart card109.

The following are the steps by which digital signature services areprovided by the smart card 109 via a request from the relying party 113to the digital signature server 117:

1. An end user 101 interacts with a relying party (RP) 113, step 301.The relying party executes a RP service 115, i.e., some form of webservice, on the relying party server 113. The end user 101 interactswith that web service 115 using a web browser 107. More specifically,the end user operates a web browser 107, which displays a web browserwindow 105 corresponding to a web browser instance of the web browser107. The web browser instance 107 communicates with the RP service 115executing on the RP server 113.

2. RP 113 asks the user to sign a document or other data, step 302.I.e., the RP service 115 executing on the RP 113 presents the user 101via the web browser window 105 the option to have the digital signatureservice 117 obtain a signature on behalf of the user 101.

3. Once the user 101 agrees, RP 113 requests the signature service fromthe DSS server 117, step 303.

4. The DSS server 117 asks the user 101 to enter the smart card PIN,step 304.

5. User enters the PIN, 305.

6. Once the smart card 109 verifies the PIN, e.g., using itsauthentication module 121, the DSS server 117 works with the smart card109 to have the smart card 109 sign the document using the private key209 inside the smart card 109, step 306.

7. The DSS server 117 returns the signed document back to RP 113, step307.

2.0 Protocol

2.1 Prior Art Protocol

FIG. 4 is a schematic illustrating the SignRequest and SignResponse in aprior art standard OASIS DSS signing protocol. The OASIS DSS signingprotocol consists of two parts: a signing request (SignRequest) 401 sentfrom a client 403, e.g., a relying party service executing on a relyingparty server, to the DSS server 405; and a signing response(SignResponse) 407 sent from the DSS server 405 back to the client 401.The SignRequest contains the document to be signed and the SignResponsecarries the signature, if the signing is successful.

The DSS messages (SignRequest, SignResponse) must be transported by somestandard communication protocols. This mapping from DSS messages to acommunication protocol is called transport binding. The DSSspecification describes several bindings. These bindings assume directcommunication protocol level connection between the client and theserver. This works fine if the DSS server can sign the document withoutthe user's help. However, when the private key is stored inside thesmart card, the DSS server must interact with the user and the smartcard in order to get the document signed. This means that the DSS servermust be able to get back to the browser, with which its client (therelying party) interacts with the user. (See FIG. 4) As such, the DSScore bindings cannot be used directly to provide transports forsignature requests and signatures for the mechanism described herein touse a user's smart card to sign documents via a digital signatureserver. Therefore, alternative bindings are introduced herein below.

2.2 Web Browser Profile

The OASIS DSS uses a centralized key management model so that signingkeys do not need to be distributed to individuals. Access controlmechanisms enable DSS to sign documents using the right keys. In orderto allow individual users to sign documents using private keys stored insmart cards or other secure storage in their possession, a new DSSprofile is described herein below, called Web Browser Profile, which isdescribed in greater detail in Section 3.0 herein below.

2.3 Transport Bindings

The transport bindings for the Web Browser Profile are derived from twobindings defined in SAML 2.0 Bindings (“Bindings for the OASIS SecurityAssertion Markup Language (SAML) v2.0”, OASIS standard, Mar. 15, 2005.):HTTP POST binding and artifact binding. These bindings allow requestsand responses to go through a user agent, e.g., a web browser operatedby a user. Using similar bindings to transport DSS messages providesopportunities for the DSS server to interact with the user's browser.These new bindings are described in greater detail herein below.

2.4 Workflow

FIG. 5 illustrates an example to illustrate the workflow of a relyingparty 113 using DSS services on a DSS server 117 to have a user 101 tosign a document using the user's smart card 109. The example uses theHTTP POST binding for both the DSS request and response. Other bindingsdescribed in section 3.2.3 Transport Bindings below (and elsewhereherein) can easily be adapted to this workflow which is merely anexample embodiment.

Herein terminology such as “relying party 113 performs action x” or “DSSservice 119 performs action y.” That terminology is consistent with themanner in which computer scientists refer to the operation of pieces ofcomputer equipment executing pieces of computer software. Of course,when it is stated that a piece of software performs an action, what isintended is that the software contains the instructions that cause thecorresponding hardware to perform that action, and, conversely, when itis stated that a piece of hardware performs an action, it is meant thatthe hardware performs the action as directed by the correspondingsoftware.

Example workflow:

1. The user 101 logs into the relying party web servicehttps://www.rp.com/115 and interacts with that web site through thebrowser 107, e.g. via browser window 105, step 501.

2. The user 101 agrees to sign a document presented by the relying partyweb service 115 by clicking a “sign” button in the browser window 105,step 502.

3. The browser 107 sends a post request (step 503): POSThttps://www.rp.com/sign HTTP/1.1

4. The RP 115 responds with a POST redirect to DSS service 119 executingon DSS server 117 via a hidden form (step 504):

HTTP/1.1 200 OK <body onload=“document.forms[0].submit( )”> <formaction=“https://www.dss-server.com/signature” method=“post”> <div><input type=“hidden” name=“SignRequest” value=“PD94bWwgdmVyc2lvbj0iM...

5. The browser 107 sends the POST request with the SignRequest (step505):

POST https://www.dss-server.com/signature HTTP/1.1

SignRequest=PD94bWwgdmVyc2lv . . .

6. The DSS service 119 responds with a smart card login page, step 506.

7. The user 101 enters the PIN to the smart card 109 through the browser107 or an external device, step 507.

8. Smart card 109 confirms the PIN, step 508. Note: if the PIN is incorrect, an error condition is detected and after a certain number oftries, the smart card 109 shuts down and the balance of the procedurewould not be executed. Appropriate error messages would be transmittedback to the DSS Service and the RP Service. The incorrect-PIN scenariois not illustrated.

9. The browser 107 sends an HTTP get request to DSS service 119 (step509):

GET https://www.dss-server.com/signature/get_dataToSign HTTP/1.1

10. DSS service 119 responds (step 510):

HTTP/1.1 200 OK

{“dataToSign”:“315d301806092a8648 . . .

11. The web client 121 executing in the browser 107 sends the data tothe smart card 109 for the smart card 109 to sign, step 511.

12. Smart card 109 signs the data and returns the signature andcertificate, step 512.

13. The browser 107 sends the signature and smart card certificate toDSS service 119 (step 513):

POST https://www.dss-server.com/signature/sign HTTP/1.1

derCert=308204623082034AA0030201 . . . &signature=69050F320B38 . . .

14. DSS service 119 responds with a success message (Step 514): HTTP/1.1200 OK

{”success“:true}

15. The browser 107 sends “finish sign” message (Step 515):

POST https://www.dss-server.com/signature/finish_sign

16. DSS service 119 sends back a SignResponse via POST redirect (Step516):

<body onload=“document.forms[0].submit( )”> <formaction=“https://www.rp.com/signResponse” method=“post”> <inputtype=“hidden” name=“SignResponse” value=“PD94bWwgdmVyc2lv...

17. The browser 107 sends the SignResponse to the RP (Step 517):

POST https://www.rp.com/signResponse SignResponse=PD94bWwgdmVyc21 . . .

18. RP service 115 sends back a page to the user's browser 107, step518.

3.0 Web Browser Profile

3.1 Overview

To allow a user to use a smart card to sign documents by selecting acertificate and corresponding private key, a DSS profile called WebBrowser Profile is defined herein. The web browser profile is based onthe OASIS DSS Core specification (“Digital Signature Service CoreProtocols, Elements, and Bindings,” version 1.0, OASIS standard, Apr.11, 2007). It introduces a new input, <Signature> element, in the<SignRequest> and further makes use of several optional elements in theCore specification. The profile also specifies new DSS bindings fortransporting DSS request and response messages through the web browser.

3.2 Profile of Signing Protocol

The Web Browser Profile allows requesting standard forms of digitalsignatures, including XML signatures (“XML Signature Syntax andProcessing (Second Edition),” W3C Recommendation, Jun. 10, 2008), CMSsignatures (R. Housley, “Cryptographic Message Syntax (CMS),” IETF RFC3852) and PGP signatures (J. Callas, et al., “OpenPGP Message Format,”IETF RFC 2440). The specific requested form is identified using the<SignatureType> identifier.

3.2.1 Element <SignRequest>

3.2.1.1 Optional Inputs Defined in the Core

None of the optional inputs defined in the core are prohibited from theWeb Browser Profile. The optional input <ClaimedIdentity> is required inthe Web Browser Profile.

3.2.1.2 Required Input <Signature>

The relying party who is making the request must digitally sign therequest using the XML signature (“XML Signature Syntax and Processing(Second Edition),” W3C Recommendation, Jun. 10, 2008.). [Note: This maybe changed to use the <SupportingInfo> child element of<ClaimedIdentity>.] The <ds:Signature> element must contain thefollowing children elements:

<ds:SignedInfo> includes signing information, such as canonicalizationmethod, signature method, transforms, digest method, and digest value.

<ds:SignatureValue> contains the value of the signature.

<ds:KeyInfo> contains information about the signing key, for example,the x.509 certificate corresponding to the signing key.

3.2.1.3 Required Optional Input <ClaimedIdentity>

The <ClaimedIdentity> is an optional input specified in the DSS Corespecification. It is a required element in the Web Browser Profile. The<ClaimedIdentity> element presents the relying party who is making therequest. The server uses this to determine if the requester is in itscircle of trust by checking relying party's metadata. The<ClaimedIdentity> contains the name of the requester using asaml:NameIdentifierType. The following is an example:

<dss:ClaimedIdentity> <saml1:NameIdentifierxmlns:saml1=″urn:oasis:names:tc:SAML:1.0:assertion″Format=″urn:oasis:names:tc:SAML:1.1:nameid- format:unspecified″>”Name”</saml1:NameIdentifier> </dss:ClaimedIdentity>

The DSS server must authenticate the claimed identity before relying onthe “Name”. The authentication can be achieved using the required input<Signature>, the “Name”, and the RP's metadata accessible by the DSSserver. The metadata must contain the “Name” as it is in the<ClaimedIdentity> and the RP's public key.

3.2.2 Element <SignResponse>

For the <SignResponse>, the Web Browser Profile defines a new optionaloutput, <ClaimedIdentity> and mandates the <Signature> element.

3.2.2.1 Optional Outputs Defined in the Core

None of the optional outputs already defined in the core are prohibitedin the Web Browser Profile. The optional output <SignatureObject> isrequired in cases of success.

3.2.2.2 Required Output <Signature>

The DSS server must sign the <SignResponse> in the form of<ds:Signature> to prove the authenticity of the message. The<ds:Signature> element must contain the following children elements:

<ds:SignedInfo> includes signing information, such as canonicalizationmethod, signature method, transforms, digest method, and digest value.

<ds:SignatureValue> contains the value of the signature.

<ds:KeyInfo> contains information about the signing key, for example,the x.509 certificate corresponding to the signing key.

3.2.2.3 Optional Output <ClaimedIdentity>

The optional output of the Web Browser Profile includes the<ClaimedIdentity> element that specifies the DSS server. It has the sameformat as the <ClaimedIdentity> in the optional input. The<ClaimedIdentity> is required in the Web Browser Profile.

3.2.3 Transport Bindings

This profile cannot use DSS core transport bindings defined in the DSSCore specification because the user browser must be involved in thebinding so that user can select the certificate for signing. The corebindings are for direct communication between the sign requester and theDSS server.

In order for RP and the DSS server to use the same web browser tointeract with the user during the DSS process, this profile defines newDSS transport bindings, which are derived from two of the bindingsdefined in SAML 2.0 Bindings, HTTP POST binding and artifact binding(“Bindings for the OASIS Security Assertion Markup Language (SAML)v2.0”, OASIS standard, Mar. 15, 2005.). These bindings allow request andresponse messages to go through an HTTP user agent. This not onlyenables the responder to interact with the user agent, but also providesopportunities for the requester and responder to interact with the sameuser agent. Therefore, this profile uses these two bindings so that theuser can be involved in the DSS process through the web browser.

The DSS request and response can use the same binding or differentbindings, depending on the usage environment or applicationrequirements. The advantage of the artifact binding comparing with theHTTP POST binding is better security because the actual DSS protocolmessage does not go through the web browser.

With the two transport bindings, there are four possible combinationsfor transporting DSS requests and responses:

1. HTTP POST binding for both the request and response;

2. Artifact binding for both the request and response;

3. HTTP POST binding for the request, and artifact binding for theresponse;

4. Artifact binding for the request and HTTP POST binding for theresponse.

The following two sections illustrate the first two bindings. The lasttwo bindings are self-explanatory based on the first two.

3.2.3.1 HTTP POST Binding

In one alternative the Web Browser Profile uses the HTTP POST bindingfor both the DSS request and response. With this binding, the DSSrequest/response exchange is accomplished through two HTTP POSTredirects.

FIG. 6 is a timing-sequence diagram illustrating the HTTP POST bindingfor DSS request and response as used by the technology presented hereinbetween a user agent 611, e.g., the web browser 107, a DSS requester613, e.g., a relying party service 115, and a DSS responder 615, e.g.,the DSS service 119. The message flow is as follows:

1. Step 601: Initially, the web browser sends an HTTP request to therelying party (RP) for signing document. When processing the request, RPdecides to initiate a DSS protocol exchange.

2. Step 602: The RP sends a DSS request via an HTTP response to thebrowser. The HTTP response is a HTTP POST redirected to the DSS server,which embeds the DSS request in an XHTML document containing a form andthe content of the DSS request. The browser submits the form to the DSSserver using HTTP POST.

3. Step 603: The DSS server interacts with the browser in order togenerate a DSS response. For example, the DSS server interacts with theuser and the user's smart card through the web browser.

4. Step 604: After creating a DSS response, the DSS server sends the DSSresponse via an HTTP response to the browser, which is a HTTP POSTredirected to the RP. The HTTP response contains an XHTML document thatincludes a form and the content of the DSS response. The web browsersubmits the form to the RP via HTTP POST.

5. Step 605: After receiving the DSS response, the RP returns an HTTPresponse to the web browser.

Note that the HTTP POST binding used in the Web Browser Profile isdifferent from the HTTP POST Transport binding defined in the DSS Corespecification. The Web Browser Profile use of HTTP POST is a HTTP POSTredirect, whereas in the DSS Core specification it is a direct HTTP POSTexchange (R. Fielding, et al., “Hypertext Transfer Protocol—HTTP/1.1,”RFC 2616).

3.2.3.2 Artifact Binding

The artifact binding transmits request, response, or both by areference, called an artifact. The requester 613 and the responder 615then use a synchronous binding, such as SOAP binding, to exchange theartifact for the actual protocol message using the Artifact ResolutionProtocol. In an alternate embodiment, the Web Browser Profile uses theartifact binding to transport the DSS request and response.

FIG. 7 is a timing-sequence diagram illustrating the artifact bindingfor DSS request and response as used by the technology presented herein.The message flow is as follows:

1. Step 701: Initially, the web browser sends an HTTP request to therelying party (RP) for signing document. When processing the request, RPdecides to initiates a DSS protocol exchange.

2. Step 702: The RP responds to the HTTP request by sending an artifactrepresenting a DSS request using an HTTP redirect through the browser tothe DSS server.

3. Step 703: The DSS server sends an <ArtifactResolve> message includingthe artifact directly to RP.

4. Step 704: The RP sends an <ArtifactResponse> message containingoriginal DSS request directly to the DSS server. This completes the DSSrequest process.

5. Step 705: The DSS server interacts with the browser in order togenerate a DSS response. For example, the DSS server interacts with theuser and the user's smart card through the web browser.

6. Step 706: After creating a DSS response, the DSS server sends anartifact representing the DSS response using an HTTP redirect throughthe browser to the RP.

7. Step 707: The RP sends an <ArtifactResolve> message including theartifact directly to the DSS server.

8. Step 708: The DSS server sends an <ArtifactResponse> messagecontaining the original DSS response directly to the RP. This completesthe DSS response process.

9. Step 709: After receiving the DSS response, the RP returns an HTTPresponse to the web browser.

3.2.4 Security Bindings

In a preferred embodiment, the Web Browser Profile uses securitybindings to carry all transport bindings. Accordingly, all digitalsignature service communications between the replying party service 115executing on the relying party server 113, the digital signature service119 executing on the digital signature server 117, the web browser 107executing on the host computer 103, and the smart card 109 are secured,e.g., using the TLS (Transport Layer Security) protocol. Furthermore,direct communication between the relying party 113 and the digitalsignature server 117 preferably is based on mutual authentication, e.g.,using TLS X.509 mutual authentication.

4.0 Software Architecture

In a preferred embodiment, the DSS software for allowing smart cardsignature in conjunction with a digital signature server according tothe herein described technology consists of two parts: the web serversoftware, i.e., the DSS service 119 and the relying party service 115,and the web client software 121 executing within the web browser 107.FIG. 8 is a block diagram illustrating the web server side softwarearchitecture, i.e., one example of the software architecture for the DSSservice 119 and the relying party service 115.

4.1 DSS Service 119

The DSS service 119 software includes a DSS service module 119 m, a DSSlibrary 801, a DSS provider tools module 803. Open source libraries andframeworks are used as building blocks.

The DSS service module 119 m contains code for a specific implementationof a DSS service 119. That code calls upon tools provided in the DSSservice provider module 803.

DSS Provider Tools Module 803

The DSS provider tools module 803 contains functionalities and interfaceof a DSS server 119. These tools provide mechanisms for the interactionswith the web client 121 or with RP service 115 directly to enable thedigital signing of documents submitted by the RP service 115.

The DSS provider module uses the DSS library 801 for DSS functionalitiesand a crypto library 813, e.g., the open source code BouncyCastle(http://www.bouncycastle.org/) to handle CMS signature.Implementation-wise, the DSS provider module 803 may be a Grailsframework plug-in (http://www.grails.org). A DSS server 119 built usingthe Grails framework can use the DSS provider module 803 plug-indirectly.

DSS Library 801

The DSS library 801 (OASIS-DSS in the illustrated example softwarestack) provides API and basic support for digital signature services.The library 801 includes:

1. Data type and object definitions;

2. Message encoding (DSS, HTTP, Base64);

3. Message decoding (DSS, HTTP, Base64);

4. Message processing;

5. Digital signing;

6. Signature verification;

7. Security rules support;

8. Metadata access.

Implementation-wise, the DSS library uses OpenSAML 807(https://spaces.internet2.edu/display/OpenSAML/Home/) for its basicfunctionalities, and uses some functionality from Apache.XML securitypackage 809 which both are open source software that may be used tosupport basic DSS functions. The DSS library 801 is a Java classlibrary, which is independent of application frameworks used by the DSSserver and relying parties.

4.2 Relying Party Server 115

The relying party server 115 has a similar structure to the DSS server119. The relying party server 115 consists of a main program and relatedprogram code 115 m implementing the functionality of the relying partyserver 115. The relying party main program and related program code 115m provides specific functionality of particular relying party services115 implementations. The relying party services implementation callsupon tools provided in the DSS RP Tools module 805 to access DSSservices.

DSS Relying Party Tools Module 805

The DSS RP Tools Module 805 provides various DSS related service API forRP web applications 115 to use. The services include metadata manager,provider security policy resolver, and requester web signature. The DSSRP Tools Module 805 uses the DSS library 801 for the basic DSS support.For example, it uses the DSS library 801 to construct DSS messages andbindings. RP web applications 811 can use the RP module 805 to accessDSS services.

4.3 Web Client Module 121

The DSS web client module 121 resides on the DSS server 117. The DSS webclient module 121 is dynamically downloaded to the web browser 107 whenthe DSS server 119 responds to a signing request from the browser 107.The DSS web client module 121 interacts with the DSS service 119 and isresponsible for the following tasks to implement the client side part ofthe signature workflow illustrated in FIGS. 3 and 5.

In a preferred embodiment, the SConnect technology (described in U.S.Pat. No. 7,748,609, to Sachdeva, Kapil et al., and entitled “System andMethod for Browser Based Access to Smart Cards”) that enables a smartcard to communicate with a remote web server securely. The web clientmodule 121 provides the following functions:

1. Allow the user 101 to authenticate to the smart card 109.

2. Receive data to be signed from the DSS service 119.

3. Send the data to the smart card 109 for signature.

4. Receive the signature and smart card certificate from the smart card109 and send these to the DSS service 119.

4.4 Summary of Example Software Architecture

In one embodiment, the digital signature service described herein forthe use of smart cards to sign on behalf of a user within the frameworkof DSS involves three software parties:

1. DSS requester, i.e. RP service 115, that requests DSS service;

2. DSS responder, i.e. DSS service 119, that provides DSS service;

3. DSS web client, i.e. web client module 121, which from within the webbrowser 107 interacts with the user 101, RP service 115, the DSS service119, and the smart card 109.

The RP service 115 can use the DSS RP module 805 to request digitalsignature service from the DSS service 119, and receiving andinterpreting the DSS response. The DSS service 119 uses the DSS Providermodule 803 to handle DSS requests and producing responses, and uses theDSS web client module 121 to interact with the user and the smart card109. Note: the DSS web client module 121 is dynamically loaded from theDSS server 117 (where it resides in persistent storage) to the webbrowser 107 when the signature services are invoked. FIG. 9 is aschematic illustration illustrating these relationships.

From the foregoing it will be apparent that a technology is presentedherein which provides an effective and elegant mechanism by which auser's smart card may be used to store a private key for use in digitalsignature services that are centralized in the manner of DSS. Themechanism provides for a relying party requesting signature services toa digital signature server which in turn relies on a user's smart cardto provide the digital signature.

Although specific embodiments of the invention have been described andillustrated, the invention is not to be limited to the specific forms orarrangements of parts so described and illustrated. The invention islimited only by the claims.

1. A method for operating a digital signature server to obtain a digitalsignature on a data item, comprising: receiving a signature request froma relying party in communication with a web browser instance on a hostcomputer; instructions to cause the web browser instance to obtain thesignature from a smart card connected to the host computer andinstructions to cause the smart card to transmit the signature back tothe digital signature server; in response to receiving the signaturerequest, transmitting the data item to the web browser instance; andupon receiving the signature from the smart card, transmitting thesignature to the relying party.
 2. The method of claim 1 wherein thedigital signature server transmits the data to be signed together withthe instructions to cause the web browser instance to obtain thesignature from a smart card connected to the host computer andinstructions to cause the smart card to transmit the signature back tothe digital signature server.
 3. The method of claim 1 or 2 wherein thedigital signature server receives the signature request in a firsttransport binding that enables the digital signature server to respondto the browser interacting with the relying party.
 4. The method ofclaim 1 or 2 wherein the digital signature server transmits thesignature to the relying party via the web browser instance executing onthe host computer using a second transport binding that causes aredirection of the response in the web browser instance to the relyingparty.
 5. The method of claim 4 wherein the first transport binding isthe same as the second transport binding.
 6. The method of claim 4wherein the first transport binding is different from the secondtransport binding.
 7. (canceled)
 8. (canceled)
 9. (canceled) 10.(canceled)
 11. (canceled)
 12. (canceled)
 13. (canceled)
 14. A system forproviding digital signature service using a private key comprising: aportable security device; and a digital signature server operable to:receive a digital signature request from a relying party via a webbrowser instance executing on a host computer wherein the digitalsignature request is transmitted to the web browser instance from arelying party; in response to receiving the digital signature request,securely transmitting data to be signed from the digital signaturenature server to the web browser instance executing on the host computerwith an indication to operate the portable security device to sign thedocument; forwarding the data to be signed from the web browser instanceexecuting on the host computer to the portable security device forsignature; the portable security device operable to: digitally sign thedata using a user private key stored on the portable security device;transmit the digital signature from the portable security device to thedigital signature server via the web browser instance executing on thehost computer; and wherein the digital signature server is furtheroperable to: transmit the digital signature from the digital signatureserver to the relying party via the web browser instance executing onthe host computer.
 15. (canceled)
 16. (canceled)
 17. (canceled)
 18. Thesystem for providing digital signature service using a private key ofclaim 14, wherein the portable security device is further operable toauthenticate the user to signing the document and to only digitally signthe document in response to successful authentication of the user. 19.The system for providing digital signature service using a private keyof claim 14, wherein the signature request message is transmitted fromthe relying party to the digital signature server over a first transportbinding protocol.
 20. The system for providing digital signature serviceusing a private key of claim 19 wherein the signature is transmittedfrom the digital signature server to the relying party over a secondtransport binding protocol.
 21. The system for providing digitalsignature service using a private key of claim 20 wherein the firsttransport binding protocol is the same as the second transport bindingprotocol.
 22. The system for providing digital signature service using aprivate key of claim 20 wherein the first transport binding protocol isnot the same as the second transport binding protocol.